feat(node): Implement registerModuleWrapper as alternative IITM/RITM wrapping method#20188
feat(node): Implement registerModuleWrapper as alternative IITM/RITM wrapping method#20188
registerModuleWrapper as alternative IITM/RITM wrapping method#20188Conversation
Semver Impact of This PR🟡 Minor (new features) 📋 Changelog PreviewThis is how your changes will appear in the changelog. New Features ✨Core
Other
Internal Changes 🔧
🤖 This preview updates automatically when you update the PR. |
size-limit report 📦
|
6c2f752 to
9192a07
Compare
node-overhead report 🧳Note: This is a synthetic benchmark with a minimal express app and does not necessarily reflect the real-world performance impact in an application.
|
| * and ModuleNameTrie. It provides a single RITM hook with trie-based module name matching | ||
| * for better performance when using many module wrappers. | ||
| * | ||
| * OpenTelemetry: Copyright The OpenTelemetry Authors - Apache-2.0 |
There was a problem hiding this comment.
(nit, I know this is still obviously wip) Guidance from legal is to include the longer license disclaimer with the link and "PROVIDED AS IS" bit, like we do in packages/core/src/integrations/express.
| /* eslint-disable no-param-reassign */ | ||
|
|
||
| import * as path from 'node:path'; | ||
| import { Hook } from 'require-in-the-middle'; |
There was a problem hiding this comment.
Presumably we'll also need a version of this for iitm, and also need to pull the relevant guts out for use in Bun, right?
There was a problem hiding this comment.
Oh, wait, nevermind, this is node-core, not core, so no bun stuff. But we do need IITM.
Part of #20171
This PR implements a new method in node-core:
This works similarly to otel wrapping, registering the patch with IITM and RITM using the same semantics, more or less. It is a bit simplified for our requirements but should generally behave the same.
registerModuleWrapperis designed to be idempotent and to be callable multiple times. It will only actually patch once, calling it subsequently will update the options though - any options required in the patch should be resolved at runtime (!) via the passed-ingetOptions. (Why, you may ask yourself? Because we rely on this for preloading OTEL instrumentation, where we run the patch in--import preload.tsor similar but do not have the options yet, which are defined later ininit(), but should update the instrumentation config accordingly).I have tentatively implemented this for the existing express instrumentation. This is def. a breaking change so nothing we can ship now but it should show how this can/should eventually look.
Note that this should not be merged as it is a breaking change and only for showcase & discussion how this can/should work.